Advertising capabilities that have no registered handlers is a sneaky source of compatibility issues — clients that enumerate capabilities and then try to call an unregistered primitive get confusing 'method not found' errors instead of a clean capability negotiation failure. Filtering at the capability advertisement level is the right place to fix this. Does the change affect the list_changed notification behavior, or is that still gated on the same registered-primitive check?

@rendina-io Good question — short answer: list_changed advertisement goes along with the capability, but the notification sending path is untouched.

The filter I added (MCPServer._filter_capabilities) only runs after the low-level server has already built ServerCapabilities in Server.get_capabilities (server.py:285-321). That existing code is what computes tools_capability = ToolsCapability(list_changed=notification_options.tools_changed) (and the prompt/resource equivalents). My filter then conditionally zeroes the whole capability (capabilities.tools = None) when zero tools are registered on the high-level MCPServer. So:

• Zero tools registered → capabilities.tools is None entirely, which means the list_changed field naturally disappears with it. That's the behavior we want: if there are no tools, there's no meaningful "tools list changed" to notify about, so not advertising it is consistent.
• ≥1 tool registered → capability is left exactly as the low-level server produced it, including its list_changed flag based on notification_options.tools_changed.

The actual notifications/tools/list_changed sending path (wherever the server emits that when the registered list mutates) isn't touched by this PR at all — it's still gated on whatever conditions it had before. So filtering at advertisement time gives clients a clean negotiation without silently dropping notifications that used to fire.

Happy to add a test that nails that invariant down (e.g. assert that with zero registered tools, initialize responds with capabilities.tools is None and therefore tools.listChanged is absent) if that'd be useful — let me know.